pay: Limit splitting when CLTV budget exhausted #8733
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Author
|
@cdecker I followed up on your feedback from #8721. This approach only triggers when CLTV budget constraints are exceeded. One of the tests covers your capacity-based example. The depth-3 limit was based on empirical testing with two paths to the destination - one with high capacity but high CLTV, another with low capacity but low CLTV. The router prefers high-capacity paths for large amounts. As splits reduce the amount, it eventually switches to the low-CLTV path:
Depth 3 caps attempts at ~30, but may fail with extreme capacity differences. I chose it as a conservative bound. Would be curious to hear your thoughts on whether a different threshold makes more sense. |
When a payment fails due to CLTV budget constraints, the adaptive splitter creates excessive sub-payments before hitting its lower amount limit. Issue ElementsProject#8167 showed partid reaching 5787+. The fix adds a cltv_budget_exceeded flag that limits split depth to 3 when CLTV constraints cause failures. Depth counts only SPLIT operations, not retries. Fixes: ElementsProject#8167 Changelog-Fixed: pay: Prevent excessive payment attempts when CLTV budget constraints are exceeded.
wqxoxo
changed the title
wqxoxo
force-pushed
the
fix/issue-8167-pay-splitter-cltv-v2
branch
from
96e3e8f to
7f72880
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a payment fails due to CLTV budget constraints, the adaptive splitter creates excessive sub-payments before hitting its lower amount limit. Issue #8167 showed partid reaching 5787+.
The fix adds a
cltv_budget_exceededflag and limits split depth to 3 when set.Depth 3 means:
This gives max 8 leaf payments exploring different amounts, which empirical testing showed is sufficient for getroute to find lower-constraint paths when they exist. The fix converts O(2^n) exponential to O(1) constant.
Depth counts only SPLIT operations, not retries. The
retry_pay_modalso creates child payments, but these are retries of the same amount, not splits. Without this distinction, retries would be incorrectly counted as depth, blocking legitimate splits prematurely.Fixes #8167